Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d21/dv_help.arc/DVCOMM.THD

Text File | 1988-03-26 | 25KB | 593 lines

@* One of the most obvious uses of a multi-tasking system like DesqView is with
telecommunications: downloading in the background, while simultaneously using
the computer to perform those jobs which require your conscious attention.
DesqView will permit you to do this, but it takes a bit of tweaking of the
system to get it to work optimally, and there are performance considerations.


@* PC-Talk

Fm: Gary Saxer (Quarterdeck) 73206,564
To: Larry Orchier 73125,14

Not only does PC-Talk work fine in DESQview, if you have a hard disk it will be
found and installed automatically!  It runs so well that you can be doing
something in the foreground while PC-Talk works in the background.  I do things
like downloads and redials while other work goes on.  Its great to get a list
of the files on a BBS and then, while downloading a big one, peruse the list to
see what else looks good.  The redialing in the background is great too! I know
of one customer (works for a phone company and checks lots of BBS's for credit
card numbers) who uses it this way all the time.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Gary Saxer (Quarterdeck) 73206,564

Yes, I agree that PCTC should work, but I was curious if your setup program did
a search for PC-TALK.EXE or PC-TALK?.EXE, which would then include all of Jim's
iterations out there (and there's a bunch) from PC-TALKA to PC-TALKB to the
present PC-TALKC...


Fm: Steve Kalman 75136,360
To: Conrad Kageyama (Sysop) 76703,1010 (X)

Connie, I have PC-TALKB on my HD and the install failed to find it. When I
changed the name to PC-TALK and reinstalled, it was found OK. (BTW, I did not
do the reinstall just to find PCT, the Add Program function works just fine!)


@* ATO

Fm: Norm Lew 70047,3340
To: Howard A. Cohen 72416,710

Under DesqView 1.2, ATO /T will run ATO in the background without any evidence
that it is running at all.  Unless of course, you use a small window, so that
you can see it running.


Fm: Vern Buerg 70007,1212
To: Norm Lew 70047,3340 (X)

Just uploaded 412 to DL4 on '129.  It supports DV. It also requires about a
180K (or larger) window.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Vern Buerg 70007,1212 (X)

A little explanation please...  According to the DOCs, DV will load any program
that is "well-behaved", i.e., use DOS or BIOS calls for the screen...  I would
assume that this would include most compiled Basic programs such as ATO and
PCTC as long as they aren't doing funny things to the screen with PEEKs and
POKEs...

Norm, in the previous message, reported that ATO ran fine in a DV window in
background...  I know that you've done a DV supported ATO in v412.  What does
it mean to be DV supported if it already ran in a DV window???


Fm: Vern Buerg 70007,1212
To: Conrad Kageyama (Sysop) 76703,1010 (X)

Any program that writes directly to the screen by placing data into the display
buffer violates the "well behaved" rule. ATO does write directly to the screen
unless the /T option is used.

The special DV-happy version of ATO uses DV's display buffer address rather
than the actual hardware address. It takes an additional DOS call and the
display is a tad slower (or jerkier), but it makes DV "aware" of what's going
on.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Vern Buerg 70007,1212 (X)

Okay, I've got that, but what's the diff between using ATO with the /T and the
DV-happy ATO???...  Both will run in background, correct???

P.S...  I didn't know that you wrote directly to screen in ATO, thought it was
all done via the compiler and normal routines..


Fm: Vern Buerg 70007,1212
To: Conrad Kageyama (Sysop) 76703,1010 (X)

The /T option forces ATO to do all screen writing via BASIC's PRINT statement.
It's noticeably slower than placing the data into the display buffer (whether
it's the hardware or DV's buffer). Only the menus use the direct write,
however.


@* Background Operation

Fm: Conrad Kageyama (Sysop) 76703,1010
To: Michael Rothman 74405,1313

Does this mean that your BBS is down???...  Or are you running it in background
and comming out thru another serial port and phone line with DV???...  If
you're not, then I take it that ATO is loaded first and is working in the
original lower 640.  Where is DOS, in the lower 640 or switched out???  WP???..


Fm: Michael Rothman 74405,1313
To: Conrad Kageyama (Sysop) 76703,1010

Yes, the bbs is down while I use the home system for connection to the sig
here.  I've only the one modem which makes it hard to run the board *and* call
cis at the same time <grin>... although I do understand that I should be able
to drive two modems from two different comm ports under dv! <I've never tried
though>.

As it happens, I run the bbs all the time in memory above 640k with no ill
effects.  When my at comes up from a boot the last thing called in autoexec.bat
is dv.bat.  That loads dv and runs an auto-start macro.  That macro opens a big
dos window of about 470k, which takes up most of my remaining lower 640k
memory.  The macro next opens a window for the bulletin board, so that it is
running in memory above 640k.  But the advantage of the rampage-at card (or
rampage) is that it does support that high memory for programs just like it is
lower 640, with the limitation that I can not open any window above 640k that
is bigger than 384k.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Michael Rothman 74405,1313

hmmm..  do you find it better to run the BBS up high, paged out rather than in
the lower 640 and let your other apps page in and out??


Fm: Michael Rothman 74405,1313
To: Conrad Kageyama (Sysop 76703,1010 (X)

Actually, Gary Saxer advised me to run the bbs in low memory, but I've been
unable to see any difference in running the board in low or high memory.  I
open a first window as my "big window", taking the best part of the lower 640k.
Then I can open many other smaller windows that get swapped in and out of low
memory, including the bbs.  So far it seems to work just fine.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Norm Lew 70047,3340

I can't *download* with PCTC with SK in the window.  I can *upload*, though!!!
However, if I load SK globally, then I can download...  Strange....

I've also set my performance to 5x5 to get the background speed up and set the
comm port to high-speed...


Fm: Norm Lew 70047,3340
To: Conrad Kageyama (Sysop) 76703,1010 (X)

I think the foreground-background ratio has no effect on download speed, unless
the work your doing in the foreground is disk intensive.  Also, if you're using
a comm program that has a large download buffer, ie Qmodem or Pibterm, you
hardly know anything is going on in the background.  You could also DL to a ram
disk..

Did you use the load.com to start PCTC ???


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Emanuel Donchin 70126,1274

The only thing that ties me up badly is comm: uploading, downloading, and DL
maintenance....  And that's the one use I need of DV.  If it weren't for comm,
I wouldn't have considered a RAMpage until Borland got all of their stuff up
high...


Fm: BARRY M. THALL 70215,1302
To: all

I am using Xtalk 3.6 and DV 1.2 on PC-2.  Is their a way to download XModem
files in the background, that is, while using another window in foreground?  So
far whenever I try all I do is lock up my Xtalk.  I've tried several configs.
to my DV-Xtalk window with no success.  Is it impossible, or have I only missed
the magic config.???


Fm: Conrad Kageyama (Sysop) 76703,1010
To: BARRY M. THALL 70215,1302

I've not actually run XTALK in background, but I have run PCTC in background
doing an XMODEM download, so it's do-able...

A number of things... did you use CT-LOAD.COM to call XTALK???  This is a must
as XTALK writes directly to screen.  In the SETUP menu, did you make the change
to High Speed Comm????  I've also changed the clock ticks to 6 and 6 to give
the background program a little more working time...  Mike Rothman has his set
for 6 and 4 and runs his BBS successfully in background that way...  And
finally, do you have any TSRs loaded???  Locally or globally??


Fm: Gary Saxer (Quarterdeck) 73206,564
To: BARRY M. THALL 70215,1302

Please be sure that you DO NOT use CT-LOAD if you are using Crosstalk 3.6.
CT-LOAD is only necessary for XTALK 3.4 and 3.5.  If you set "Writes directly
to screen" and "Runs only in Foreground" OFF (not highlighted) XTALK works
great in the background.


Fm: BARRY M. THALL 70215,1302
To: Gary Saxer (Quarterdeck) 73206,564

Thanx for the info, only it does work!!!  Have loaded xtalk as you said
(to the letter), am using 1200b Hayes, and load xtalk 1st.  It works well in
background EXCEPT when I try to move it to background in a Xmodem download, the
program locks up.  Any ideas?


Fm: Gary Saxer (Quarterdeck) 73206,564
To: BARRY M. THALL 70215,1302 (X)

Well, you might try changing your foreground/background parameters in advanced
SETUP under Performance.   Try 10 5 to give more time to background processing.
I have found XTALK to not fit the XMODEM spec to the letter regarding retries,
which should happen every so often.  If you are running 3.6 I am very suprised
since it seems to be much better at this.  Perhaps it has to do with the host.
I will try it again myself and check it out.  Are you familiar with a public
domain program to use in 3.5 which you run in XTALK which sigificantly improves
its XMODEM capabilities?


Fm: Jim Butler 74766,1460
To: Conrad Kageyama (Sysop) 76703,1010 (X)

I saw the "High Speed Comm" Option in the Advanced Setup on DV 1.2, but scoured
the manual for any explanation.  What does it mean to set it to "Y" or "N" in
the Setup?


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Jim Butler 74766,1460

yep, I saw no mention either...  Mike Rothman put me on to it... Apparently
setting it to Y gives the comm port a higher priority...


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Jim Butler 74766,1460

Sorry it's not in the manual, it was added after printing and we feel that it
is more of an "esoteric" option that is used by a small number of users.
Settinf "High Speed COMM" to Y will make communications interrupts the highest
priority.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Gary Saxer (Quarterdeck) 73206,564

Right!!...  I noted that info in the manual, but due to some strange quirk, if
I load SK in my comm window (PC-TALKC), I can't download with XMODEM.  I can
upload fine, but I can't download...  And I need to have SK handy, so I'm
loading it globally for now...  I'm gonna look into loading SK into its own
window just as soon as I get some time.  At least right now I'm functional.


Fm: Jim Butler 74766,1460
To: Gary Saxer (Quarterdeck) 73206,564

What does it mean to put communications interrupts in highest priority?  Should
it make comm programs go faster?  Why?  It cuts down on background window
ticks?


Fm: Earle Robinson 70135,141
To: Gary Saxer (Quarterdeck) 73206,564

Is there any difference between 10 5 and 18 9?  I should think not, but perhaps
I am wrong.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Gary Saxer (Quarterdeck) 73206,564

I know that Mike Rothman, on an AT, is using 6 and 4 to run his BBS in
background, and I set mine at 6 and 6 to try to improve PCTC in the background.
Would 10 and 5 be a better setup for most all programs with relaxed XMODEM
timing???..  Is there any rule of thumb in setting up the clock tick ratios??


Fm: Don Singleton 76154,26
To: Conrad Kageyama (Sysop) 76703,1010 (X)

What happens when you try to download with Xmodem with SK in your comm window?
How much memory is left for PCTC (I got some strange problems associated with
xmodem when I tried to restrict it below 190K).


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Don Singleton 76154,26 (X)

With SK loaded via a batch file for a PCTC window, I allocated 250K of RAM,
which loaded the package with no problems.  When attempting an XMODEM download
with PCTC, I get as far as "Receiving File with XMODEM", but I never get the
"Holding for Start".  I'm then dead in the water...


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Don Singleton 76154,26 (X)

Darn...  the light finally blinked on in my head...  I'll try upping the RAM
allocation in my window and see if that makes a difference in XMODEM
downloading...


Fm: Don Singleton 76154,26
To: Conrad Kageyama (Sysop) 76703,1010 (X)

I hope that that will help.  If I correctly interpreted 212379, it looks like
you only had 250K for SK and PCTC, which would certainly not leave PCTC with
the the required 190 - 200K if you were using the full blown SK, and if you
were using one of the subsets it might or might not.  I never got it to act
just like you describe, but I got several different types of lockups, as I was
trying to squeeze it into various amounts of restricted memory.  My most
frequent hangup was an out of string space and then crash back to DOS, but I
had others (don't remember exactly what they were).  Basically you need
something around 190K for the version I have available at the time you load
PCTC.  I am currently running it in 207K, but I am pretty sure I have cut it
down to something in the low 190s.


Fm: BARRY M. THALL 70215,1302
To: Conrad Kageyama (Sysop) 76703,1010 (X)

No go.  I made all the changes you suggested and while the main terminal xtalk
program works well, no way will the xmodem download (on CIS) in the background.
I'm open to other suggestions, but am becoming pessimistic.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: BARRY M. THALL 70215,1302

Did you see Gary Saxer's message to you wherein you are NOT supposed to use
CT-LOAD.COM on 3.6???..  You must have the XTALK.PIF file in the same directory
as XTALK.EXE though....  BTW, I neglected to ask, but I assume that you have no
problems downloading with XTALK when you're NOT in DV???..


Fm: BARRY M. THALL 70215,1302
To: Conrad Kageyama (Sysop) 76703,1010 (X)

Yes I did see Gary's message.  Xtalk works fine on its own and it also
downloads fine in the 'current' dv window.  What it doesn't do is xmodem
download in the background.  I have changed just about everything in the 'load
file' for dv, and it aint NO GO. What's interesting is that the download
doesn't bomb (in CIS), it just sits there until the window is made active, then
sits there somemore until it receives a magic message from CIS and continues
the download with the next appropriate block.  Too bad, background downloading
would be right up there with the most important functions of 'multi-tasking'
software like dv.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: BARRY M. THALL 70215,1302

hmmm... let's see...  you've set your high speed comm to Yes, and you've
changed the clock ticks so that you're closer to Gary's configuration... Have
you tried increasing the amount of memory allocated to the program??? If I
recall, it's defaulted to 96K or something like that...  Have you tried
cranking it up to about 150K?????...


Fm: Conrad Kageyama (Sysop) 76703,1010
To: BARRY M. THALL 70215,1302

Okay, let me ask one more question, and MIND YOU, I am NOT the expert here.
When you run XTALK in the current window, can you run it i.e., download, in a
small window, or do you have to be full screen???....  This question, in my
thinking, would indicate whether or not the XTALK.PIF file is being handled
properly by DV, or if DV is even aware of it...


Fm: BARRY M. THALL 70215,1302
To: Conrad Kageyama (Sysop) 76703,1010 (X)

Connie, I appreciate your interest.  Xtalk runs fine, downloads Xmodem, et. al.
either full screen, or in any size window you heart desires, AS LONG AS it's
the active window.  Even accessing DV w/ the ALT key to change the size of the
window, or to do other cosmesis to the window, causes the Xmodem download to
halt for 30-45 secs. until it gets something from CIS which causes it to pick
up where it left off.  Do other Xmodem programs behave the same?


Fm: Paul Ferrara 70075,252
To: BARRY M. THALL 70215,1302

I just downloaded a file via Xtalk 3.6 from a local BBS. I did it both from
within DV, in the background, and then exited XTalk & DV while maintaining the
connection and did it again.

From within DV in the background, 50 xmodem blocks took 1:07.  From straight
DOS, it took 1:03.  Xtalk indicated no errors either time, even during the
switchovers and zooming.  I could watch the activity in the Xtalk window, while
I worked in the other window.

I should add that Fri night, I tried this with while communicating with a
friend and got errors when I switched.  At that time I had my performance ratio
at 6:4 and had 3+ windows open and a large dBase process going on at the same
time.  I was too chicken to close anything up for fear of disrupting the dBase
program.

Tonight I set the ratio to 5:5 and only had Xtalk in the background.  I'm
running an XT with the NEC chip.

p.s.  I do notice a considerable slowdown when capturing threads, so do not use
DV while doing this.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Paul Ferrara 70075,252 (X)

hmmm...  I'm running 6/4 also...  You say it seems to work better at 5/5???
Does their seem to be any noticeable slowdown in the foreground???..  What if
we went bass-acwards and did a 4/6 or somesuch, when telecomm is in background?


Fm: Paul Ferrara 70075,252
To: Conrad Kageyama (Sysop) 76703,1010 (X)

I was going to try 4:6 but since it works *well* at 5:5, I'd be inclined to go
the other way.  I assume that the background share gets divided by all programs
running in the background, so that was probably my problem the other night.


Fm: BARRY M. THALL 70215,1302
To: Paul Ferrara 70075,252

1/ try to download from CIS with Xmodem on Xtalk 3.6 while in a DV background
window.  If this works for you then #2/ (please).  Could you explicitly recount
exactly your Xtalk DV setup file, your order of load, when you can switch the
download window to the background, etc, etc.  If this can be done from CIS I'd
give my left ear to know how.  I've tried everything (I thought).  BTW, I also
am on an XT w/ the V20 chip.


Fm: Paul Ferrara 70075,252
To: BARRY M. THALL 70215,1302

I'm confident that since it works on a BBS, it'd work on CIS. One thing to
remember in this regard, though, is that I'm in Columbus and calling in direct.
That may make a difference.  I am satisfied that message downloads are
sufficiently slowed that I'm not going to be using DV for that purpose.

My Xtalk set-up is as follows (these are *on*):

Uses its own colors, Allows keyboard type-ahead, Allows TopView calls, Allows
script type-ahead, Close on exit to DOS

I have the xtalk.pif file in my Xtalk directory and had two windows open at the
time (#1 & #2).  Xtalk was in #1.  I also erred in reporting the time slicing I
was using.  It was 4:6; not 5:5.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Paul Ferrara 70075,252 (X)

You *did* have background cranked up!!!  I'll try it then...  BTW, one BIG plus
I noticed tonite with PCTC and XMODEM.  I don't know if it was intentional by
Jim, accidental, or just an idiosyncrasy of my machine, but each block received
causes a little "crackle" of the speaker...  I can be running PCTC in
background downloading XMODEM and have a full screen in the foreground and
still tell that the download is progressing nicely because of the "crackles"...
When there's no sound, I take a peek at the comm window by zooming down the
current window... cute!!...


Fm: Paul Ferrara 70075,252
To: Conrad Kageyama (Sysop) 76703,1010

Crackling??  That is interesting.  Didn't know he'd included that "feature."
<grin>  Since you have a free account, why don't you try Xtalk.  Start with 6:4
and let me know.   That brings up an interesting question.  Wonder why xmodem
doesn't slow the system but a read does?


Fm: Conrad Kageyama (Sysop) 76703,1010
To: BARRY M. THALL 70215,1302

I loaded XTALK 3.6 in background and did a number of XMODEM downloads with it
while doing other things in foreground...  I even swapped one program to disk
to see if it would interfere...  I had the same params as Paul plus CANNOT swap
to disk and the clock ticks at 5:5 and the high speed comm switch set to yes.


Fm: Conrad Kageyama (Sysop) 76703,1010
To: Paul Ferrara 70075,252

As noted in another message, I did try XTALK and it worked fine in background
too, though I need to keep visible a window large enough to see the block xfer
line in XTALK....  As for the whys and wherefores, I don't know enough about
the mechanics of the thing, but I would guess that it has to do with a read
being a continuous flow and DV having to do something about it, while blocks
can be handled in toto in each cycle of clock ticks...


Fm: Jim Butler 74766,1460
To: Conrad Kageyama (Sysop) 76703,1010

Are you saying you notice no visible slowing in xmodem with xtalk running in
background in DV? <wow!>


Fm: Paul Ferrara 70075,252
To: Gary Saxer (Quarterdeck) 73206,564

For some reason, capturing the message base here is slowed considerably (@ 2400
bps) where xmodem transfers click along just as fast as if DV was not running.
This is true whether or not XTalk is running in the foreground or background.
Is there anything DV is doing that could be changed via setup, to improve this
situation.


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Paul Ferrara 70075,252

Paul, I'm just guessing, but it could have to do with the fact that messages
have to write their stuff to the screen, which, even when zoomed, is really
being shared with other programs.  The XMODEM download is not scrolling (the
worst offender as far as speed goes) and so you notice little difference.  You
may want to try upping your background ticks.  Another change might be to set
"Jump Scroll" (in SETUP, Performance) to Y.  The scrolling won't be as smooth
but it will be faster.


Fm: Earle Robinson 70135,141
To: Paul Ferrara 70075,252 (X)

How much slowing?  I have only tried one download of msgs in background & found
that there was perhaps a 10% slowing, though even that I can't be sure of since
I didn't try the same running pro-yam alone outside of dv.

It is not impossible that pro-yam is faster than most others anyway.  Someone
left me a private message yesterday in which he said that he had just got
pro-yam and found the download speeds much faster than those obtained with ato.


Fm: Gary Saxer (Quarterdeck) 73206,564
To: Bill Brown 76003,36

I can give you 2 hints for starters: 1) If the program "writes directly to
screen", that is it does NOT use DOS or BIOS calls to write onto the screen,
then you will have trouble running it in background because it will type on top
of whatever else you may be doing on the screen.  There is a way around this if
you have the source to the code. 2) If the program "spins its wheels" waiting
for something to happen (like the phone to ring or someone to type a
character), then your foreground program will appear to run a little more
slowly.  Once again there are several ways around this if you have the source.
The only other problem you may have is that the bbs will have to be
nonswappable.  This means that it must not be allowed to be put aside to disk.
This may use up more memory than you would be willing to give.  The workaround
to this is to get a RAMpage board.


Fm: Paul Ferrara 70075,252
To: ALL

Got Watson running under DV tonight and it's slick.  It's TV/DV aware so it
runs in a window and in the background just fine.  In conjuction with the VIS
module which gives you up to 500 mailboxes, it'd make a nice voice mail system
without tying up a cpu.


Fm: Nelson Ford 71355,470
To: Paul Ferrara 70075,252 (X)

Does Watson actually answer the phone, etc., in the background? If so, what
happens if you are doing some disk-intesive job at the time - does it take
over, or what?


Fm: Paul Ferrara 70075,252
To: Nelson Ford 71355,470

Nelson, Watson sure does answer in the background.  While it was doing it's
thing, I use the DIR command and LF29.  Watson was not affected, either on the
outgoing or incoming messages (I was calling in from a second line).  I'm
impressed.  Paul